-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[skip-ci] Make leak-detection readable by humans #21459
Conversation
The intended output urls should look something like what I've linked below for "shows url" against this reference PR. I've also linked the exact "workflow" for each event. Example URLs shown in workflow log: Note: I made this list by manually copy-pasting based on what the code changes should Edit: If it helps, in each "workflow" link, there's a |
23e7035
to
95eaef6
Compare
Previously when a leak was detected under any circumstance, the workflow would splat out a giant wall of gray, unreadable git-log text. This often enormous text might contain, somewhere, possibly, maybe, a little tiny snippet of code that leaks a secret. Improve the situation greatly by providing easy-to-use URLs that covers the relevant changes based on the triggering context (new pr, force-push, or merge). Store the former (often) giant git-log output into a file and stuff it into the artifacts in case it's ever useful. Signed-off-by: Chris Evich <cevich@redhat.com>
95eaef6
to
28856b6
Compare
@edsantiago @lsm5 not super-critical, but when you get a chance PTAL. I'm hoping this should ease the pain of checking for leaks based on a flood of podman-monitor e-mails. This doesn't make the leak-review task completely effortless, but at least it colorizes the diff in green and red, and offers a 'hide' button for each file in the commit 😄 |
LGTM |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cevich, rhatdan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
LGTM |
Previously when a leak was detected under any circumstance, the workflow would splat out a giant wall of gray, unreadable git-log text. This often enormous text might contain, somewhere, possibly, maybe, a little tiny snippet of code that leaks a secret.
Improve the situation greatly by providing easy-to-use URLs that covers the relevant changes based on the triggering context (new pr, force-push, or merge). Store the former (often) giant git-log output into a file and stuff it into the artifacts in case it's ever useful.
Does this PR introduce a user-facing change?